Synchronization of encryption in a wireless communication system

ABSTRACT

Disclosed embodiments include a method for synchronizing a cryptosystem. In one embodiment, the method uses existing control data that is transmitted as part of a connection establishment process in a wireless communication system. In one embodiment, messages that are normally sent between a base station and a remote unit during the setup of both originating and terminating calls are parsed to detect a particular control message that indicates the start of telephony data transmission. Detection of this message indicates a point at which encryption/decryption can begin, and is used to synchronize the cryptosystem. Synchronizing a cryptosystem involves generating an RC4 state space in a keyed-autokey (“KEK”) encryption system. In one embodiment, Lower Medium Access Channel (“LMAC”) messages are used according to a wireless communication protocol. This is convenient because the LMAC messages are passed through the same Associated Control Channel (“ACC”) processing that encrypts and decrypts the telephony data.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional PatentApplication No. 60/256,668, filed Dec. 19, 2000, which is incorporatedherein by reference in its entirety.

BACKGROUND

[0002] The disclosed embodiments relate to data transmission in wirelesscommunications systems.

[0003] Data transmissions include telephony data and other data, such ascontrol data. In typical wireless telecommunications environments, it isimportant to provide security for the telephony data transmitted on aradio frequency (“RF”) channel between a wireless network subscriber'smobile unit and a fixed base. Secure communication allows users to beconfident their communications are private and guarded from fraud.

[0004] Various techniques for securing telephony data transmitted overthe RF channel include encrypting the telephony data for transmissionover the RF channel. The telephony data is decrypted when received.Encryption techniques often employ a mathematical algorithm that altersor rearranges the telephony data using a key. A corresponding key mustbe used to decrypt the telephony data. Keys are usually changedperiodically for security. One challenge for designers of suchtechniques is the need to synchronize the encryption mechanisms forequipment and/or software at the sending and receiving locations.Synchronization includes assuring that the sender and the receiver areusing a current key, and the sender and receiver are encrypting anddecrypting at an appropriate point in a transmission.

[0005] Synchronization must be established initially and maintained,even through situations in a wireless environment such as signal fadingand handoff of an ongoing telephony call from one base station toanother. Encryption synchronization in a wireless communication systemcan be difficult because the base station and remote unit are physicallyseparated, and also because telephony calls (including low-speed modemcalls and facsimile calls) are relatively asynchronous (e.g., noconnection without an active call).

[0006] Prior approaches to encryption and synchronization have variousdisadvantages such as added signal processing overhead and time. Forexample, one technique used with a secure radiotelephone requires anadditional infrared (“IR”) link to establish and maintain encryptionsynchronization. Another method involving analog scrambling of thetelephony data uses an additional sub-audible signal for continuoussynchronization of the scrambled audio signal. One method forresynchronization of the encryption system after a handoff requires aprocessing delay that is in addition to any normal handoff delay

[0007] Overall, there is a need for synchronization of encryption thatavoids the above disadvantages while providing secure wirelesscommunication.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008]FIG. 1 is a block diagram of an embodiment of a telephony systemthat may employ an encryption method under one embodiment of theinvention.

[0009]FIG. 2 is a block diagram of an embodiment of a base station.

[0010]FIG. 3 is a block diagram of a message flow for connectionestablishment for a terminating call in one embodiment.

[0011]FIG. 4 is a block diagram of a message flow for connectionestablishment for an originating call in one embodiment.

[0012]FIG. 5 is a diagram of an ACC/traffic channel frame in oneembodiment.

[0013]FIG. 6 is a diagram of an ACC message format in one embodiment.

[0014]FIG. 7 is a diagram showing the format of a TCH_CONN_REQ in oneembodiment.

[0015]FIG. 8 is a diagram illustrating the mapping of pKeySeed tokeySeed in the encryption method of an embodiment.

[0016]FIG. 9 is a diagram of a partial airlink DSP software architecturein a fixed wireless system (“FWS”) of one embodiment.

[0017]FIG. 10 is a diagram of elements of a software architecture of anairlink DSP in one embodiment.

[0018]FIG. 11 is a diagram of elements of a software architecture of anRC4 software architecture within the airlink DSP in one embodiment.

[0019]FIGS. 12A and 12B are a flow diagram of an embodiment ofencryption synchronization for a terminating call.

[0020]FIG. 13 is a flow diagram of an embodiment of encryptionsynchronization for an originating call.

[0021]FIGS. 14 and 15 are block diagrams that further illustrateembodiments of encryption synchronization.

[0022]FIG. 16 is a diagram of one byte of an encryption key string,illustrating key generation according to an embodiment.

[0023]FIG. 17 is a diagram of an encryption key string, furtherillustrating key generation according to an embodiment.

[0024] In the drawings, the same reference numbers identify identical orsubstantially similar elements or acts. To easily identify thediscussion of any particular element or act, the most significant digitor digits in a reference number refer to the figure number in which thatelement is first introduced (e.g., element 204 is first introduced anddiscussed with respect to FIG. 2).

[0025] Note: the headings provided herein are for convenience and do notnecessarily affect the scope or interpretation of the invention.

DETAILED DESCRIPTION

[0026] Embodiments of the invention, described below, use existingcontrol data to synchronize a cryptosystem in a wireless communicationsystem. In one embodiment, messages in a standard format that includescontrol data and payload data are processed, including determiningwhether the control data contains a particular control message. Messagesnormally sent between a base station and a remote unit during the setupof both originating and terminating calls are parsed to synchronize anevolving RC4 state space in a keyed-autokey (“KEK”) encryption system.In one embodiment, Lower Medium Access Channel (“LMAC”) messages areused according to a wireless communication protocol. This is convenientbecause the LMAC messages are passed through the same Associated ControlChannel (“ACC”) processing that encrypts and decrypts the telephonydata. This is also effective because the particular LMAC messages usedare sent each time connection establishment occurs. Once a dataconnection has been established, each side must know when to startencrypting and decrypting the bit stream. One embodiment includessoftware that detects a particular LMAC message that is always sentbefore completing a connection establishment process and just before thetransmission of telephony data. This is also the point at which it isdesirable to begin encryption synchronization. The LMAC message servesas a trigger that initiates an encryption synchronization process,including starting an encryption synchronization counter that operatesto determine the point in the transmission at which encryptionsynchronization should begin. The particular LMAC messages are sent orresent each time a connection must be established. Thus, encryption isautomatically resynchronized for any call initiation or interruptionwithout additional layers of software or hardware.

[0027]FIG. 1 is a block diagram of an embodiment of a telephony system100. The telephony system 100 includes remote units (“RUs”) 102, 104,and 106, and base stations 108 and 110. The number of base stations andRUs is exemplary, and could vary in any particular instance. The RUs102, 104, and 106, and the base stations 108 and 110 each containvarious electronic circuitry to process control and data signals, suchas digital signal processors (“DSPs”). The base stations 108 and 110,and in some embodiments the RUs 102, 104, and 106, further contain acentral processing unit (CPU) and one or more memory devices for storingdata including software routines executed by the CPU.

[0028] Any of the RUs can establish a telephony data connection withanother RU in the system 100 or out of the system 100 through one of thebase stations, such as base stations 108 or 110. An RU typicallyestablishes a telephony connection with a base station in closestproximity. During a call, the call may be “handed off” from one basestation to another. For example, RUs 104 and 102 preferably establishtelephony connections with the base station 108. The RU 106 preferablyestablishes a telephony connection with the base station 108, but thecall that is establishes could be handed off to the base station 110.

[0029]FIG. 2 is a block diagram of an embodiment of a base station 200.The base station 200 includes a telephony DSP 202, an airlink DSP 204, aCPU, 206, and a memory device 208. The memory device 208 storesinstructions and data, including in one embodiment, instructions forsynchronizing encryption. In other embodiments, the instructions forsynchronizing encryption are stored in other memory devices, or accessedvia a network. As further explained herein, embodiments of the softwareinstructions for synchronizing encryption include a master encryptionswitch that is active when encryption is to be performed. Embodiments ofthe software instructions for synchronizing encryption further includean encryption synchronization counter that is loaded with the size of astandard message being sent so that the end of the transmission and thepoint at which encryption should start can be determined.

[0030] The telephony data exchange involves multiple layers of softwareand hardware. For example, at a physical layer, the telephony data andother data, such as control data, is processed by an airlink digitalsignal processor (“DSP”) for transmission over an established airlink.In one embodiment, encryption of telephony data is performed by atelephony DSP. The encryption as well as the synchronization ofencryption is handled at an associated control channel (“ACC”) softwarelayer. As described in more detail below, existing ACC messages areparsed to provide encryption synchronization in the normal course ofconnection establishment.

[0031] FIGS. 3 and 4 illustrate a message flow in one embodiment forconnection establishment for a terminating call and an originating call,respectively. A terminating call is a call in which the RU is thereceiver, while the RU is the initiator of an originating call.Referring to FIGS. 3 and 4, the respective diagrams each list systemlayers across the top of the diagram, with base station layers on theleft and RU layers on the right. The base station layers and RU layersmeet at the physical layer, PHY, as shown. The labeled arrows eachrepresent a message and its direction, that is from base station to RU,or vice versa. The sequence in which the messages occur is illustratedby time advancing from top to bottom in the diagrams.

[0032] During the establishment of a telephony connection, before voicedata is being transmitted, it is not necessary to encrypt or decryptdata for security. In any case, if encryption mechanisms are not firstsynchronized between sender and receiver, the voice data may beunintelligible. Therefore, in one embodiment, a place in the messageflow is identified that is common to all telephone calls after the DSPinitiates a traffic channel, but before any telephony data exchange. Asshown in FIGS. 3 and 4, both terminating and originating calls use the“set asynchronous balance mode” (“SABM”) and “set asynchronous balancemode unnumbered acknowledge” (“SABMUA”) messages in their setup.Moreover, the direction of a SABM message is always from RU to basestation, while the direction of a SABMUA message is always from basestation to RU. In addition, these are LMAC messages that are passedthrough the ACC processing on the DSP. In one embodiment, it is the ACCprocessing that encrypts and decrypts the telephony data using the RC4methodology. Thus, it is convenient to place the mechanism forcryptosystem synchronization at this level of processing. The RC4methodology is a known encryption/decryption methodology developed byRon Rivest, and will be explained further below.

[0033] The nature of typical telephony communication (which includesvoice data, low-speed modem data, and fax data) is such that dataexchange according to a protocol is always occurring after callestablishment, even if no telephony data is being exchanged. Thischaracteristic is used advantageously in keeping the cryptosystemsynchronized. There is a chance, in deep fading environments, for atelephony channel to be completely lost. This requires the RU and basestation to reestablish a telephony data channel. During the channelreestablishment, transfers of SABM and SABMUA messages occur. The term“SABM/SABMUA message” will be used to indicate a message that is eithera SABM message or a SABMUA message. Because the original SABM/SABMUAmessages were used in the original cryptosystem synchronization, it isadvantageous to use the SABM/SABMUA messages for resynchronizing thecryptosystem in the case of a reestablishment of a telephony datachannel.

[0034] The ACC and its message types will now be briefly discussed onlyto the extent necessary to explain their role in embodiments ofencryption synchronization. In one embodiment, an ACC messageencompasses three message types, which are link control channel (“LCC”)messages, telephony control channel (“TCC”) messages, and physicalcontrol channel (“PCC”) messages. An airlink DSP in a base station actsas a router. The LCC's client is a control CPU in the base station. TheTCC's client is a telephony DSP in the base station, and the PCC'sclient is a physical management software entity.

[0035]FIG. 5 is a diagram of an ACC/traffic channel frame 500. TheACC/traffic channel frame 500 consists of 132 bits. Twelve bits are ACCbits 502, and 120 bits are data payload bits 504. The ACC bits 502 arean ACC message that is limited to twelve bits per frame. If an ACCmessage is longer than twelve bits, additional frames are used totransmit the ACC message. In one embodiment, the frame rate for thetraffic channel frame 500 is 7.5 ms/frame. Therefore, the amount of timeit takes a normal message to complete is equal to the size of themessage in bytes times 7.5 ms.

[0036]FIG. 6 is a diagram of an ACC message format in one embodiment.The ACC frame 600 consists of four header bits 602, and 8 payload bits604. The four header bits 602 include a “more bit”, designated “M”, andthree type bits. The more bit indicates whether or not the message iscomplete. If the more bit is active, the ACC message continues in thenext frame. The three type bits encode a frame type as shown in theframe list 606. Each ACC frame transmitted contains the four header bits602 so that multi-frame messages can be superseded by higher prioritymessages. For example, this is necessary for TCC messages because theactual data for the TCC message is contained in one of the three 40-bitsub-frames of the traffic data, and cannot be held off. In oneembodiment, the frame type defines four values: no message, LCC, TCC,and PCC. When there is no ACC traffic, the frame type is set to 00.While ACC data exists on the channel, the frame type corresponds to themessage type (LCC, TCC, or PCC). There are four reserved message types,which may be used to implement a fast channel type message, which mayuse the 120 bits of payload from the ACC/traffic channel frame 500, ifnecessary.

[0037] The eight bits of payload are available for each ACC frame. ForLCC and PCC messages, the payload is routed to or from the destinationor source, respectively. The payload in a TCC message determines whichof the three 40-bit frames received/transferred contain TCC messages.

[0038] As will be further explained below, the ACC messages are parsedto determine whether the message being sent is a SABM/SABMUA message.The transmission of a SABM/SABMUA indicates that the process ofestablishing the connection is being completed, and the next datatransmitted will be telephony data that should be encrypted ordecrypted. Thus, the SABM/SABMUA messages are used to synchronizeencryption between a sender and receiver.

[0039] The encryption methodology of one embodiment will now bediscussed. In one embodiment, RUs are provisioned withinstallation-based encryption keys or, alternatively, per-callencryption keys. Encryption keys for traffic channel data are 128-bitarrays of data and are derived from a message digest. A softwareapplication executing on the base station CPU handles the generation ofthe message digest as well as the derivation of the 128-bit trafficencryption key sequence. Generation of a message digest is based on asecure hash function, such as the Secure Hash Standard (SHS: FederalInformation Processing Standard 180-1).

[0040] The airlink DSP is not involved in the key-exchange andauthentication process, but is involved in applying CPU-suppliedencryption keys to voice traffic data. The encryption key is passed tothe airlink DSP by the CPU via a traffic channel connect request(TCH_CONN_REQ) message. FIG. 7 shows a format of the TCH_CONN_REQmessage, although other formats are possible. The message header 702 andmessage body 704 contain conventional information related to the trafficconnect request. The encryption information 706 gives a currentencryption state of the sender, including a current cipher, orencryption, key size and a current cipher key. The cipher key size isthe size of the RC4 encryption key in bytes. In one embodiment, theairlink DSP can support unique uplink and downlink cipher keys for eachchannel. The TCH_CONN_REQ message can only support a single cipher key.

[0041] In one embodiment, Rivest's Cipher 4, commonly known as RC4, maybe used in the cryptosystem. RC4 is a stream cipher that is relativelysimple to implement, in part because the software code size is not largecompared to other methods. In addition, RC4 offers string encryption andsymmetry: the same program code is useable for both encryption anddecryption.

[0042] With RC4 there are some caveats on acceptable keys. Some keyshave been found vulnerable to brute force attacks, and some statisticalevidence was shown to this effect (Seehttp://www.tik.ee.ethz.ch/˜mwa/RC4/WeakKeys.txt).

[0043] A state box (S-box) for RC4 encryption is an array of data thatis key and stream-length dependent. Stream-length dependence is animportant contributor to the strength of the cryptosystem. It is notrequired that the stream size of the transmitter and receiver be thesame. However, S-box synchronization is achieved at the beginning of thecall. In one embodiment, the airlink DSP contains the encryptionimplementation rather than the telephony DSP because the airlink DSP hasrelatively greater program and data memory availability.

[0044] According to the RC4 Algorithm, an 8 X N-bit encryption key isdelivered to the RU as part of the traffic channel connect message. Aninitial state box (S-box) is generated from the N byte encryption keyaccording to the algorithm below expressed in pseudocode.

[0045] PSEUDOCODE FOR RC4 S-BOX INITIALIZATION For indices from 0 to255, inclusive S-box [index] = index K-box [index] = key [index mod N]j-index = 0 for indices from 0 to 255, inclusive j-index = (j-index +S-box[index] + K-box [index]) mod 256 swap S-box[index] with S-box[j-index]

[0046] Over time, the S-box evolves with each byte encrypted/decrypted.The run-time RC4 algorithm is:

[0047] PSEUDOCODE FOR RC4 ENCRYPTION/DECRYPTION

[0048] For each byte in the specified buffer (buf) i-index =(i-index + 1) mod 256; j-index = (j-index + S-box[i-index] mod 256; swapS-box [i-index] with S-box [j-index] mod 256; t = (S-box [i-index] +S-box [j-index]) mod 256; ciphbyte = bufXOR S-box[t]

[0049] The i-index and j-index are one-time initialized to 0. Theirvalues are saved from function call to function call to ensure a slowS-box shuffle.

[0050] Given the particulars of the algorithm, this function set canprovide services to any function requiring strong encryption. Goodstartup synchronization should be provided between the transmitter andreceiver.

[0051] PRIVATE PERSISTENT DATA STRUCTURES

[0052] A data structure per duplex data stream if the RC4Key may be asfollows: typedef struct { Rc4KeyOneWay rx; Rc4KeyOneWay tx; UINT116keySeedSize; } Rc4Key;

[0053] The size of the keySeedSize may be limited to 32 bytes. Since theS-Box evolves with each byte input, a key box space is defined for eachcommunications path (receive and transmit). typedef struct { UINT8 S[256]; UINT8 i; UINT8 j; UINT8 keySeed [RC4_KEY_SEED_SIZE]; }Rc4KeyOneWay;

[0054] In one embodiment, RC4_KEY_SEED_SIZE is defined to be 32.Although UINT8 is officially a UINT16, it serves as a reminder thatquantities in the RC4 function module reference bytes. The user hasflexibility to specify different keySeeds for each direction. In oneembodiment, the user is a system administrator who sets up theencryption algorithm using a specific software application. In oneembodiment, the software application is a traffic application running onthe airlink DSP that uses the encryption system. A simplex RC4 key boxstructure is defined. A simplex RC4 key box structure is inexpensive interms of memory, and further increases the security of the links. Eachencrypted, full-duplex data channel requires 583 words of data memory.All RC4 key sets are maintained by the RC4 function module.

[0055] APPLICATION PROGRAM INTERFACE

[0056] There are five functions callable by the user: InitRC4,SetKeySize, SetKeySeed, PrepareKey, and RC4. Function prototypes for theRC4 function module are as follows: void InitRC4 (void); RC4ResultSetKey Size (Rc4keyType keyType, UINT16 keyId, UINT16 keySize);RC4Result SetKeySeed (Rc4KeyType keyType, UINT16 keyId, Rc4KeyDirectionkey Dir, UINT16 *pKeySeed); RC4Result Preparekey (Rc4KeyType keyType,UINT16 keyId, Rc4KeyDirection key Dir); RC4Result RC4 (Rc4KeyTypekeyType, UINT16 keyID, Rc4KeyDirection keyDir, UINT8 *pBuffer, UINT16bufferLen);

[0057] The next three subsections describe input and output data types.The subsections following the I/O data types describe the interfaces andconditions of the five user callable functions above (i.e. the RC4function module).

[0058] RC4RESULT

[0059] The first data type, RC4Result, is an enumerated data type theuser may exploit to determine the execution of most of the public RC4functions. An example of a data structure for RC4Result is as follows:typedef enum { RC4_KEY_OK, RC4_KEY_INVALID, RC4_KEY_WEAK,RC4_BUFFER_LENGTH_0, RC4_KEY_TRUNCATED, RC4_BAD_DIRECTION } RC4Result;

[0060] An explanation of each of these results is given with theappropriate access function.

[0061] RC4KEYTYPE

[0062] The second data type, Rc4KeyType describes the type of key touse. Under one embodiment, the only type of key used is for voicetraffic, although alternative embodiments may define key types for othertraffic. typedef enum { TrafficRc4Key, MaxKeyTypes } Rc4KeyType;

[0063] RC4KEYDIRECTION

[0064] Because each key set is comprised of two key boxes (receive andtransmit), this third enumerated data type spells out those directionsexplicitly. typedef enum { Rc4Receive, Rc4Transmit, MaxRc4KeyDirections} Rc4KeyDirection;

[0065] RC41NIT

[0066] The first user callable function, RC4INIT, is an initializationfunction that takes no inputs or outputs. It initializes all RC4function module key sets. This function must be called before any otheraccess functions. Additionally, it may be used only for one-timeinitialization since it does initialize all supported key sets. In oneembodiment, two voice traffic channels are supported, althoughalternative embodiments may support additional voice channels, or voicechannels and channels for other data.

[0067] SETKEYSIZE

[0068] With reference to Table 1, as the name suggests, the key size ofa key set is set by the second user callable function, SETKEYSIZE. Thekey size is shared with both transmit and receive paths. The functionattempts to retrieve a specified key set. If the key set is retrieved,then the function sets the keySeedSize field to the smaller of thespecified keySize or RC4_KEY_SEED_SIZE. TABLE 1 RC4Result Output ofSetKeySize RC4Result Interpretation RC4_KEY_OK All is well, the keySizewas accepted for the specified keytype and keyId. RC4_KEY_ The specifiedkeyType and/or keyId is not valid. INVALID The keyType must beTrafficRc4Key. The keyId must also be appropriate: TCHA or TCHB.RC4_KEY_TRUN- The specified keySize was too large for the CATED keySeedarray stored in the Rc4KeyOneWay structure. There it was truncated tothe maximum supported size, RC4_KEY_SEED_SIZE.

[0069] SETKEYSEED

[0070] With reference to Table 2, this user callable function sets thekeySeed array of a specified Rc4OneWay structure using the pKeySeedarray as a source. So that the user need not know all the peculiaritiesof the RC4 function module, the pKeySeed array may be an unsigned arrayof 16-bit elements. For implementating this function, pKeySeed may be apacked character array. The keySeed is an array of up RC4_KEY_SEED_SIZEbytes. The pKeySeed is an array of 16-bit words. One example of theorder in which the pKeySeed bytes are stuffed into the keySeed is shownin FIG. 8, “Mapping pKeySeed to keySeed”. This mapping is done tofacilitate S-box preparation. A small increase in complexity here,further decreases the complexity in the PrepareKey access function.

[0071] The flow of this access function is to attempt to retrieve thespecified key box entry. If the function successfully retrieves the keybox entry, then the pKeySeed is mapped as an array of 16-bit values tothe keySeed of the key box (as shown in FIG. 8, which illustratesmapping pKeySeed to keyseed. TABLE 2 RC4Result Output of SetKeySeedRC4Result Interpretation RC4_KEY_OK The keySeed was copied to thespecified key box successfully. RC4_KEY_INVALID The specified keyType,keyId, or keyDir was not valid for setting the seed. keyType must beTrafficRc4Key. keyId must be TCHA or TCHB. keyDir must be eitherRc4Receive or Rc4Transmit.

[0072] PREPAREKEY

[0073] Referring to Table 3, this function initializes a specified keybox according to its keySeed. Like most of the access functions, theoutput is returned as an RC4Result. TABLE 3 RC4Result Output ofPrepareKey RC4Result Interpretation RC4_KEY_OK Everything occurredcorrectly. The key box specified is ready for use. RC4_KEY_INVALID Thekey set specified by keyType, keyId, or keyDir is not valid. KeyTypemust be TCHA or TCHB. KeyDir must be either Rc4Receive or Rc4Transmit.

[0074] PrepareKey must be called for each direction in a key set.

[0075] RC4

[0076] The RC4 function is the encryption/decryption implementation ofthe RC4 algorithm. Given a key box and a buffer to operate upon, RC4churns out the ciphertext or plaintext (depends on a value of the keydirection “keyDir”). Note, the pBuffer has a UINT8 type specification.This means that the pBuffer must be a least-significant-byte-justifiedarray of bytes in order to work properly. RC4 does not check to makesure the pBuffer is zero padded in the most significant bytes of thearray. A keyDir of Rc4Receive will take a ciphertext pBuffer of lengthbufferLen, and replace the contents of pBuffer with its plaintextversion. Similarly, a keyDir of Rc4Transmit will replace a plaintextpBuffer of bufferLen with its ciphertext version. Meanwhile, for validbufferLens, the S-box is evolving with the RC4 algorithm.

[0077] VOICE ENCRYPTION SOFTWARE ARCHITECTURE

[0078] The way in which the RC4 function module fits into the generalairlink software architecture will now be discussed Basically, the ACCand control level traffic channel (“TCH”) tasks handle all of therelevant RC4 interfacing. FIG. 9 is a representation of a partialairlink DSP software architecture 900 in one embodiment of a fixedwireless system (“FWS”). The architecture 900 is a generalized model ofa processing core of a two-channel voice system. The details are that ofthe ACC and the relevant portion of the TCH tasks. The CPU 902communicates with an airlink DSP 906 through a host port interface(“HPI”) pipe interface, and with a telephony DSP 904 through an HPImailbox interface. The DSPs 904 and 906 communicate with each otherthrough a time division multiplex (“TDM”) inter-DSP interface. Referencenumber 1000 indicates the airlink DSP 906 and its immediate environmentin the software architecture as illustrated in further detail in FIG.10.

[0079] Referring to FIG. 10, further detail of the airlink DSP 906 andit immediate environment in the software architecture 1000 of oneembodiment are shown. The airlink DSP 906 includes an HPI driver 1004through which a high-speed data (“HSD”) signal 1012, a network accesscontroller (“NAC”) signal 1010, a TCH signal 1008, and an ACC signal1006 access the HPI pipe interface. A tone driver 1014 receives tonesfrom a TDM tone bus interface. The received tones are translated into anHSD signal 1012, a NAC signal 1010, and a TCH signal 1008. Processingthe TCH signal 1008 yields the ACC signal 1006, which goes to a TDMdriver 1002. Between the TCH signal 1010 and the HPI driver 1004 is aTCH service access point (“SAP”). Between the ACC signal 1006 and theHPI driver 1004 is a ACC SAP. The TDM driver 1002 communicates with aTDM inter-DSP interface. The software architecture 1016 that includesthe ACC signal 1006 and the TCH signal 1008 is further illustrated inFIG. 11.

[0080]FIG. 11 is a diagram of an embodiment of the software architecture1016 that illustrates how the RC4 software module fits into the ACC andTCH signals. The software architecture 1016 includes an ACC functionmodule 1102, a TCH SAP function module 1104, and an RC4 function module1106. The RC4 function module 1106 includes the functions SetKeySize,SetKeySeed, PrepareKey, and RC4 described above.

[0081] The SetKeySize and SetKeySeed functions are callable by the TCHfunction module 1104 via direct control lines to perform voiceencryption set up. The TCH function module, in the idle state, reacts toa TCH_CONN_REQ message, which requests a connection, by calling anencryption set up function 1108. The encryption set up function 1108accesses the RC4 function module 1106 to set the encryption key size andto set the encryption key seed. When the idle state is reentered, anencryption tear off function 1116 is called, terminating the set upprocess.

[0082] The PrepareKey and RC4 functions are callable by an ACC TDMmanagement entity 1110 and an ACC traffic management entity 1112 of theACC function module 1102. As seen as pseudo code in the ACC trafficmanagement entity 1112, if the receive side of voiceSecure is on and theSABM/SABMUA message is detected, the entity 1112 can initiatesynchronization of the cryptosystem by calling the PrepareKey and RC4functions. In one embodiment, voiceSecure is a variable that indicateswhose purpose is to signify when the encryption synchronization iscomplete so that a next block of data to be transmitted or received willbe encrypted. As shown in the ACC CPU management entity 1114, if theSABM/SABMUA message is detected in the incoming message, RC4synchronization can be started. The ACC CPU management entity 1114communicates with the ACC TDM management entity 1110, which checks forvoiceSecure on (master encryption switch on). The ACC TDM managemententity 1110 further checks for an LCC airlink packet with a transmitflag on. If the transmit flag is on, the encryption synchronizationcounter is decremented. If the encryption synchronization counter iszero, the ACC TDM management entity 1110 initializes the encryptionsynchronization by calling the PrepareKey function and the RC4 function.

[0083] RC4 KEY BOX SYNCHRONIZATION

[0084] The present state of an RC4 S-box depends on the keySeed and thelength of the data stream (in bytes); an RC4 S-box can be any one ofabout 2¹⁷⁰⁰ states. Therefore, proper synchronization is to bemaintained for the duration of a data channel. The RU to basesynchronization is a well-behaved software package in most existingwireless networks, so only strict synchronization on data channelstartup is required.

[0085] VOICE CHANNEL SYNCHRONIZATION

[0086] In the illustrated embodiments, RC4 synchronization is achievedthrough the use of existing messaging related to connectionestablishment, or voice traffic setup. The RC4 function module islogically close to the ACC function module, so some known portion of itsmessaging may be used for RC4 synchronization. ACC communicates with theLMAC of the base station and the RU. This message SAP is peer-to-peer,meaning that it passes messages between the RU and the base station overthe allocated airlink. The usefulness of this communication is clearwhen applied to initial synchronization of the voice securityalgorithms.

[0087] Because of the desire to start encryption as close to the startof the traffic channel as possible, (after examining the originating andterminating call setup flows of FIGS. 3 and 4) synchronizing each linkon the SABM/SABMUA messaging is possible. Uplink is synchronized onSABM, while downlink is synchronized on SABMUA. Any call setup requiresthe SABM/SABMUA message transfer. This facilitates the RC4synchronization maintenance.

[0088] By synchronizing the encryption on the SABM/SABMUA signaling,special handling of quadrature phase shift keying (“QPSK”) handover canbe neglected because, as far as the airlink is concerned, a new voicecall is generated. The RC4 functional module is integrated with the ACCfunction module. Putting the encryption module as close (in a data flowsense) to the data source (the telephony DSP) as possible, simplifiesthe handling of encryption. Conveniently, the ACC is also responsiblefor passing the SABM/SABMUA messages to the CPU. This makes for cleanintegration with minimal external effects to be compensated for. Inother embodiments, other messages that occur predictably can be used tosynchronize encryption. A system architecture determines the specificprotocols used for establishing a connection. Therefore, any callestablishment that uses a predictable message or series of messages canuse an embodiment of the invention.

[0089]FIGS. 12A and 12B are a flow diagram of an embodiment ofencryption synchronization for a terminating call, or a call in which abase station establishes a connection with an RU. At block 1202, thebase station CPU begins transmitting a LCC message to an airlink DSP. Inone embodiment, the instructions stored on the memory device 208 (FIG.2) include a software program for synchronizing encryption. The softwareprogram includes a master encryption switch that indicates whetherencryption is required or not. The software program further includes anencryption synchronization counter that assures thatencryption/decryption is synchronized, as will be explained below.

[0090] At block 1204, it is determined whether the master encryptionswitch is active. The master encryption switch is set at call set upwhen the host directs a traffic channel to be started. In oneembodiment, the DSP makes the determinations referred to. If the masterencryption switch is not active, no encryption/decryption is currentlyrequired, and the LCC message is queued for traffic processing at block1209. If the master encryption switch is active, it is then determinedat block 1206 whether the message currently being sent is a SABM/SABMUAmessage. If the message is not a SABM/SABMUA message, the LCC message isqueued for traffic processing at block 1209. The SABM/SABMUA messagesoccur at a recognizable point in connection establishment, and indicatewhen telephony data will be sent. In particular, the SABM/SABMUA messageis the last message sent before the telephony data. The LCC message isnot encrypted, but the telephony data is encrypted. Because data istransmitted in blocks, and because the size of the LCC message isvariable, it is necessary to determine where the LCC message stops andthe telephony data starts. The encryption synchronization counter istherefore loaded with the number of LCC message bytes to be transmitted,including the SABM/SABMUA message. When the encryption synchronizationcounter is zero, encryption/decryption can begin.

[0091] If the message is a SABM/SABMUA message, at block 1207 the numberof LCC message bytes to transmit (including the size of the SABM/SABMUAmessage) is put into the encryption synchronization counter, and theencryption synchronization counter is started. This is the beginning ofencryption synchronization. The LCC the message is queued for trafficprocessing at block 1209.

[0092] Traffic processing begins with block 1208. When 120 bits oftelephony (payload) data have been assembled, an ACC message byte isretrieved and prioritized at block 1208. These messages have priority,as previously described, and can preempt LCC messages. At block 1210, ifthe master encryption switch is on and the encryption synchronizationcounter is started, it is determined at block 1212 whether the messageis an LCC message. If the message is not an LCC message, then processingpasses to block 1220, where an airlink packet is created. If the messageis an LCC message, the encryption synchronization counter is decrementedby one at block 1213. If the encryption synchronization counter is zeroat block 1214, an RC4 state box is generated at block 1216, using acurrent key. If the encryption synchronization counter is not zero atblock 1214, an airlink packet is created at block 1220. When the RC4state box has been generated, encryption has been synchronized and thesystem can begin encrypting and decrypting data. The encryptionsynchronization counter is stopped at block 1218, and an airlink packetis created at block 1220.

[0093]FIG. 13 is a flow diagram of an embodiment of encryptionsynchronization for an originating call, or a call in which an RUestablishes a connection with a base station. An ACC message is parsedfrom a received airlink packet at block 1302. As discussed withreference to FIGS. 5 and 6, and further below, 132 bits are received. 12bits of the 132 bits are ACC bits and 120 bits are payload bits. Atblock 1304, if the master encryption switch is not on, an LCC packet iscreated to be sent to the base station CPU. If the master encryptionswitch is on at block 1304, it is determined whether the current messageis a SABM/SABMUA message at block 1306. If the message is not aSABM/SABMUA message, an LCC packet is created to be sent to the basestation CPU. If the message is a SABM/SABMUA message, an RC4 state boxis generated at block 1310, and an LCC packet is created at block 1310.

[0094] At this point, the synchronization should be with a “new” RC4key. If an “old” RC4 key is used, the system could be attacked. In oneembodiment, an additional algorithm is used to generate a new RC4 key.Both the RU and the base station know the algorithm, and may use it togenerate a new key. The SABM/SABMUA message synchronize the new RC4state boxes, and transmission continues. RC4 key generation will bediscussed in more detail below.

[0095]FIGS. 14 and 15 are block diagrams that further illustrateembodiments of encryption synchronization. In one embodiment, FIGS. 14and 15 are a block diagram of the ACC function with respect toencryption synchronization. FIGS. 14 and 15 group the function into 3sections: section 1402 is LCC message receipt from the CPU by theairlink DSP; section 1404 is traffic processing by the airlink DSP; andsection 1502 is generation of the RC4 state box by a telephony TDMtransceiver. The arrangement of functions and entities in the figures isexemplary, and other arrangements of functions and entities arecontemplated within the scope of the invention.

[0096] Referring to FIG. 14, LCC message receipt function 1402 andtraffic processing function 1404 are shown in the airlink DSP. In thetransmit direction, an LCC message is received from the CPU. If themaster encryption switch is on and the LCC message is a SABM/SABMUAmessage, then the number of LCC message bytes to transmit is counted,including the size of the SABM/SABMUA message, and loaded into theencryption synchronization counter. This begins the encryptionsynchronization process.

[0097] Referring to traffic processing function 1404, when 120 bits oftelephony data have been assembled, an ACC message byte is retrieved.ACC message bytes have priority as previously discussed. Only TCCmessages can preempt LCC messages.

[0098] If the master encryption switch is on and the encryptionsynchronization counter was started, then the encryption synchronizationcounter is decremented by one. If the encryption synchronization counteris zero, then a transmit RC4 state box is generated at block 1506, andthe encryption is considered synched. The encryption synchronizationcounter is stopped, and an airlink packet is created.

[0099] In the other direction of transmission, upon receipt of a 132 bitairlink packet 1406 from the airlink, the ACC is parsed from the packet.

[0100] If the master encryption switch is on and the ACC contains aSABM/SABMUA LCC message, then a receive state box is generated at block1508, and the receive cryptosystem is considered synchronized. An LCCpacket is created for transmission to the CPU.

[0101] At this point, the resynchronization may use a “new” RC4 key. Notto do so could open the system to attack. Therefore, an additionalalgorithm is used to generate a resend key. In one embodiment, aswitch-tail shift register is used to generate a new key. Both the RUand the base station know this algorithm, and use it to generate a newkey. New key generation is discussed more fully below, but first statebox generation will be discussed with reference to FIGS. 14 and 15.

[0102]FIG. 15 is a block diagram showing aspects of a state boxgeneration function 1502 that performs state box generation in atelephony TDM transceiver on the airlink DSP. A generate RC4 function1506 generates the transmit state box, while a generate RC4 function1508 generates the receive state box. On the receive end, an airlinkpacket 1406 is received from the telephony DSP and parsed to separate 12ACC bits “Z” from the 40 payload bits “Y” (the 120 payload bits are sentin three blocks of 40 payload bits each). If the master encryptionswitch is active and encryption is synched (this means that theencryption synchronization counter is zero), the RC4 state box isgenerated at block 1508 according to the method described above. Thepayload data is encrypted by exclusive-ORing it with the state box dataas previously described, and the result, “B”, is used to create anairlink packet. If the master encryption switch is not active or theencryption is not synched, the payload data is not encrypted.

[0103] On the transmit end, telephony data from the base station isparsed. The 12 bits of ACC data “A” are sent to traffic processing 1404.If the master encryption switch is active and the encryption is synched,then the RD4 state box is generated, and the payload data is encryptedas previously described. If the If the master encryption switch is notactive or the encryption is not synched, the payload data is notencrypted.

[0104]FIGS. 16 and 17 illustrated an embodiment of RC4 key generationthat occurs on encryption resynchronization. The process uses a Mobiusstrip function to generate new key bytes in each place of the keystring. In one embodiment, the specific polynomial used on each byte ofthe key is x⁷+x⁴+x³+x+1. This is shown in FIG. 16, which is a diagram ofone byte of the key string with the bits labeled 0 through 7. Using thefirst bit, each bit corresponding to the polynomial is exclusive-ORedwith the first bit. Then, each bit is shifted up in the array. Theexclusive-OR operations occur before the shifting operations.

[0105] To further obfuscate the key, the same process is applied to thewhole key. The key is shown in FIG. 17. The key includes 16 bytes, withbyte 0 shown at the top of the diagram. Using the first key byte, eachbyte corresponding to the polynomial is exclusive-ORed with the firstkey byte (byte 0). After which, each key byte is shifted up in thearray. The exclusive-OR operations occur before the shifting operations.

[0106] Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense as opposed to anexclusive or exhaustive sense; that is to say, in a sense of “including,but not limited to.” Words using the singular or plural number alsoinclude the plural or singular number respectively. Additionally, thewords “herein,” “hereunder,” “above”, “below,” and words of similarimport, when used in this application, shall refer to this applicationas a whole and not to any particular portions of this application.

[0107] The above detailed descriptions of embodiments of the inventionare not intended to be exhaustive or to limit the invention to theprecise form disclosed above. While specific embodiments of, andexamples for, the invention are described above for illustrativepurposes, various equivalent modifications are possible within the scopeof the invention, as those skilled in the relevant art will recognize.For example, while steps are presented in a given order, alternativeembodiments may perform routines having steps in a different order. Theteachings of the invention provided herein can be applied to othersystems, not necessarily the wireless communication system describedherein. The various embodiments described herein can be combined toprovide further embodiments. These and other changes can be made to theinvention in light of the detailed description.

[0108] Any references and U.S. patents and applications listed above areincorporated herein by reference. Aspects of the invention can bemodified, if necessary, to employ the systems, functions and concepts ofany patents and applications described above to provide yet furtherembodiments of the invention.

[0109] These and other changes can be made to the invention in light ofthe above detailed description. In general, the terms used in thefollowing claims, should not be construed to limit the invention to thespecific embodiments disclosed in the specification, unless the abovedetailed description explicitly defines such terms. Accordingly, theactual scope of the invention encompasses the disclosed embodiments andall equivalent ways of practicing or implementing the invention underthe claims.

[0110] While certain aspects of the invention are presented below incertain claim forms, the inventors contemplate the various aspects ofthe invention in any number of claim forms. For example, while only oneaspect of the invention is recited as embodied in a computer-readablemedium, other aspects may likewise be embodied in a computer-readablemedium. Accordingly, the inventors reserve the right to add additionalclaims after filing the application to pursue such additional claimforms for other aspects of the invention.

I/we claim:
 1. A method for synchronizing a cryptosystem in a wireless communication system, the method comprising: processing a message for transmission, wherein the message includes control data and payload data, and wherein the control data is not encrypted; determining whether the control data contains a particular control message; if the control data contains the particular control message, loading an encryption synchronization counter with a number of control message bytes to be transmitted and initializing the encryption synchronization counter; when the encryption synchronization counter is decremented to zero, indicating that the entire message has been transmitted, initializing the cryptosystem using a key; using the cryptosystem to encrypt the message; creating an encrypted airlink packet for transmission over an airlink; receiving an encrypted message, including control data and payload data, over the airlink; parsing the message to separate the control data from the payload data; determining whether the control data contains the particular control message; if the control data contains the particular control message, initializing the cryptosystem using the key; and using the cryptosystem to decrypt the message.
 2. The method of claim 1, wherein the particular control message is a final link control channel (“LCC”) message transmitted before the transmission of payload data begins, and wherein transmission of the final link control channel occurs each time a call over an airlink channel is set up.
 3. The method of claim 1, wherein initializing the cryptosystem includes operating on a state box using the key.
 4. The method of claim 1, wherein initializing the cryptosystem comprises: performing a mathematical operation on the key to alter the key for security, wherein the key is an array of data; and operating on a state box using the altered key, wherein the state box is an array of data.
 5. The method of claim 1, wherein the cryptosystem includes an RC4 state box and an RC4 key, and wherein the payload data is operated on using the RC4 state box for encryption and decryption.
 6. A method for synchronizing a cryptosystem between a sender and a receiver in a wireless network comprising at least one base station and at least one remote unit, the method comprising: detecting a particular control message at an associated control channel (“ACC”) level that is sent each time an airlink channel is set up; and in response to detecting the particular control message, determining a point in the transmission at which to begin operating the cryptosystem, including changing an encryption key that is used by the base station and the remote unit.
 7. The method of claim 6, wherein the particular control message is a final control message sent before payload data is sent
 8. The method of claim 6, further comprising using the changed encryption key to generate a state box that is used by the base station and the remote unit to perform encryption and decryption.
 9. The method of claim 6, wherein the operation of the cryptosystem occurs at the ACC level.
 10. The method of claim 6, further comprising: loading an encryption synchronization counter with a size of an ACC message that contains the particular control message, wherein the ACC message is transmitted in blocks; decrementing the encryption synchronization counter to zero when a last block of the ACC message has been transmitted; and when the particular control message has been detected and the encryption synchronization counter is zero, initializing the cryptosystem.
 11. The method of claim 6, wherein the particular control message is either a “set asynchronous balance mode” (“SABM”) message or a “set asynchronous balance mode unnumbered acknowledge” (“SABMUA”) message.
 12. The method of claim 6, wherein the cryptosystem includes an RC4 state box that is generated by the encryption key.
 13. A wireless communication system, comprising: at least one remote unit comprising, at least one digital signal processor (“DSP”); a central processing unit; and a memory device, wherein the at least one remote unit is configured to receive data from and send data to at least one base station; and at least one base station comprising, at least one DSP; a central processing unit; and a memory device, wherein the at least one base station is configured to detect a particular control message in a data transmission and, in response, initiate an encryption/decryption process, wherein the particular control message is an associated control channel (“ACC”) message that occurs just before the transmission of telephony data.
 14. The system of claim 13, wherein initiating the encryption decryption process includes the base station transmitting an encryption key via a traffic channel request message, and wherein the encryption key is used by the remote unit and the base station to generate a state box.
 15. The system of claim 13, wherein the at least one DSP of the base station comprises an airlink DSP including a memory that contains a software architecture, the software architecture comprising: an ACC function module; and a traffic channel (“TCH”) function module, wherein initiating the encryption/decryption process includes the ACC function module and the TCH function module accessing an encryption/decryption function module to prepare an encryption key and begin the encryption/decryption process using an encryption/decryption algorithm.
 16. The system of claim 15, wherein the encryption/decryption algorithm is an RC4 algorithm.
 17. The system of claim 13, wherein the particular control message is selected from a group comprising a “set asynchronous balance mode” (“SABM”) message and a “set asynchronous balance mode unnumbered acknowledge” (“SABMUA”) message.
 18. A computer-readable medium whose contents cause a transmitter in a communications system to perform a method for synchronizing encryption/decryption of transmitted data, the method comprising creating a packet for transmission over a link, including: sending messages in blocks of data from a central processing unit (“CPU”) to a communication link digital signal processor; detecting a particular control message in the blocks of data; in response to detecting, loading a size of a message into a counter, wherein the counter reaches zero when all of the blocks in the message have been sent; when the counter reaches zero, initiating an encryption/decryption synchronization process, including generating a state box using an encryption key; and encrypting transmissions following the message for the packet.
 19. The computer readable medium of claim 18, wherein the method further comprises creating a control message packet for sending to the CPU, including, receiving an airlink packet; parsing the airlink packet to separate payload data from control data; detecting a particular control message in the airlink packet; in response to detecting, initiating an encryption/decryption synchronization process, including generating a state box using an encryption key; and decrypting data following the particular control message.
 20. The computer readable medium of claim 18, wherein the packet comprises the encryption key.
 21. The computer readable medium of claim 18, wherein initiating the encryption/decryption synchronization process further includes changing the encryption key according to a predetermined algorithm, and operating on the state box using the changed encryption key.
 22. The computer readable medium of claim 18, wherein the method is performed at an associated control channel level of processing.
 23. The computer readable medium of claim 18, wherein the method is performed each time the base station participates in setting up an airlink channel.
 24. The computer readable medium of claim 18, wherein the particular control message is a link control channel (“LCC”) message that is a “set asynchronous balance mode” (“SABM”) message and a “set asynchronous balance mode unnumbered acknowledge” (“SABMUA”) message.
 25. An apparatus for synchronizing an encryption /decryption process in a wireless communication network, comprising: at least one digital signal processing means; at least one central processing means; and encryption synchronization means configured to detect a particular control message in a data transmission and, in response, initiate an encryption/decryption process, wherein the particular control message occurs just before the transmission of telephony data.
 26. The apparatus of claim 25, wherein the encryption synchronization means is further configured to provide a current encryption key to receiving devices and sending devices in the wireless communication network.
 27. The apparatus of claim 25, wherein the encryption synchronization means is further configured to count data blocks in a message being transmitted to determine when to begin encryption/decryption.
 28. The apparatus of claim 26, wherein initiating the encryption/decryption process comprises using the current encryption key to generate a current state box, wherein the current state box is used to operate on the telephony data.
 29. The apparatus of claim 25, wherein the encryption synchronization means and the encryption/decryption process operates at an associated control channel level in the wireless communication network.
 30. The apparatus of claim 25, wherein the initiation of the encryption/decryption process occurs each time a wireless connection is set up, comprising initial connection, connection hand off, and connection reestablishment after unexpected connection loss.
 31. A cryptographic method, comprising: detecting a particular trigger upon establishment of a wireless telephony communication link between at least one wireless transmitter and one wireless receiver, wherein the communication link is established under at least one known wireless protocol, and wherein the particular trigger is at a know time or location under the communication link establishment of the known wireless protocol; and in response to detecting the particular trigger, determining a point in the transmission at which to begin applying a stream cipher.
 32. The method of claim 31, wherein the particular trigger is either a “set asynchronous balance mode” (“SABM”) message or a “set asynchronous balance mode unnumbered acknowledge” (“SABMUA”) message sent at an associated control channel (“ACC”) level each time an airlink channel is established.
 33. A method of synchronizing an encryption data array at a transmitter to a decryption data array at receiver in a wireless communication network, the method comprising: establishing a call between the transmitter and the receiver using a call establishment message transmitted from the transmitter to the receiver; parsing the call establishment message to produce a parsed call establishment message; determining an encryption state of the transmitter based on the parsed call establishment message; and synchronizing the decryption data array at the receiver based to the encryption data array at the transmitter based on the encryption state of the transmitter. 